[レポート] Simplifying multi-tenancy with SaaS applications on AWS Fargate に参加しました #SVS329 #AWSreInvent
こんにちは! AWS 事業本部コンサルティング部のトクヤマシュンです。
ラスベガスで開催されている AWS re:Invent 2024 に参加しています。
本記事は AWS re:Invent 2024 のセッション「SVS329 | Simplifying multi-tenancy with SaaS applications on AWS Fargate」のセッションレポートです。
Fargateを使ってマルチテナントSaaSアプリケーションを展開する時に抑えておくべき考え方がまとまっていた良セッションでした。
セッション
タイトル
SVS329 | Simplifying multi-tenancy with SaaS applications on AWS Fargate
概要
There is a growing trend to build SaaS solutions on Amazon ECS. Developing multi-tenant SaaS applications requires addressing multiple concerns, including tenant isolation, tenant onboarding, tenant-specific metering, monitoring, and other SaaS aspects. In this session, explore how to manage multi-tenancy aspects when deploying solutions on Amazon ECS with AWS Fargate.
Chat GPTによる和訳:
Amazon ECS 上で SaaS ソリューションを構築する動きが増えています。マルチテナントの SaaS アプリケーションを開発するには、テナントの分離、テナントのオンボーディング、テナント固有のメータリングや監視、その他の SaaS 特有の要件に対処する必要があります。このセッションでは、AWS Fargate を使用して Amazon ECS 上にソリューションをデプロイする際に、マルチテナンシーに関連する要素をどのように管理するかを探ります。
スピーカー
- Nathan Peck, Senior Developer Advocate, Amazon
他セッション情報
Session types: Breakout session
Topic: Migration & Modernization, Serverless Compute & Containers
Area of interest: Modernization, Monitoring & Observability
Level: 300 – Advanced
Role: Developer / Engineer, DevOps Engineer, IT Professional / Technical Manager
Services: Amazon Elastic Container Service (Amazon ECS), AWS Fargate
前提
本セッションの内容に入る前に、マルチテナントSaaSについて、はじめにいくつか前提となる情報をお伝えします。
- 複数のテナント(利用者の単位)が同じシステムを利用する
- テナントは平等ではなく、Tierというランク付けが存在することが多い
- コントロールプレーンとアプリケーションプレーンを持つ
- コントロールプレーン:管理を担う。テナント管理、ユーザー管理、管理者、など。
- アプリケーションプレーン:SaaSのアプリケーションを担う。
ECSでマルチテナントSaaSを構築する時の一例は、たとえば次のようなものです。
AWS におけるマルチテナント SaaS の実装パターン ~ Amazon Elastic Container Service (Amazon ECS) 編より
ここではこれ以上の詳細は触れません。下記をご確認ください。
はじめに
セッションはこんな説明から始まりました。
Building a SaaS = building customer trust
SaaSを作ることは顧客の信頼を築くことと等しい。なるほどと思いました。
そして、顧客がSaaSに抱く信頼とは下記のことだと述べていました。
- I trust your software to be available when I need it
- I trust your software to keep my data secure
- I trust your software to get new features I need
- I trust your business to be here for the long term
セッションはそれぞれについて詳しい説明をするという流れで進みましたので、レポートもそのように進めます。
I trust your software to be available when I need it
意訳すると、「SaaSにはいつでも必要な時に使える状態であってほしい」となります。
要は可用性の話です。可用性はゼロイチではなくて連続性のものだと述べられていました。
マルチテナントで可用性を考えるときには、isolation(分離性)が重要です。これにより障害の影響を一部のみにとどめます。
ECSでの分離性の例として、デプロイ時のローリングアップデートとデプロイサーキットブレーカーの話がありました。
どちらも異常時の影響を全体に及ぼさず一部に留めるための仕組みと言うことができると思います。
また、障害時の外部影響を減らすにはcellular architectureが良いと話されていました。
人物の大小はテナントのTierを表しており、それぞれの環境のTier合計を近づけることで、障害時の影響の偏りを防ぐ、という考え方のようです。
画像だと大のTierが小の2倍だとすると、すべての環境のTier合計が等しくなっています。
Noisy Neighbor(うるさい隣人)問題もあります。特定の利用者のふるまいによって共存するほかの利用者に悪影響を及ぼすことですね。
セッションではNoisy Neighbor対策にはスロットリングが効果的だと述べられていて、API GatewayのAPIキーを利用した方法や、テナントごとにECSタスクのvCPU・メモリを制限する方法が述べられていました。
I trust your software to keep my data secure
意訳すると「SaaSにはいつでも私のデータをセキュアに扱ってほしい」となります。
セキュリティについてもisolationが大事で、マイクロサービスアーキテクチャが有効だという話がありました。
そして、それぞれのマイクロサービス間のセキュリティはファイアウォールやIAM Roleで保護します。
ECSですと下記のようになります。
・ネットワークモードにawsvpcモードを利用し、タスクごとにセキュリティグループを設定してファイアウォールとして利用
・タスクごとにIAMロールを設定し、適切な権限を与える
ただし、マルチテナントの場合は他スクロールだけでなく、テナントごとに必要な権限も加味した上で権限設定するのが良い、と話されていました。
セッション内ではこの例として、DynamoDBのリソースベースルールでテナントごとにアクセス可能な範囲を制限する、という話がありました。
I trust your software to get new features I need
意訳すると「SaaSにはいつでも私が必要とする機能を提供してほしい」となります。
ただ、機能開発にかかる工数と運用にかかるオーバーヘッドはトレードオフの関係にあります。
クラウドを使うことで、運用にかかるオーバーヘッドを減らしてビジネス価値に関わる機能開発に集中できます。
たとえば、Fargateを使ってインフラ部分の運用オーバーヘッドを下げること。
他にはCDKを使うことで、事前に定義されたパターンでサービスを構築してインフラ検討にかかる時間を減らすこともできます。
FargateについてはECS Service extensionsを使うことができます。
I trust your business to be here for the long term
意訳すると「SaaSは長期間にわたってサービスを提供してほしい」となります。
そのためにはいかにコスト効率よくマルチテナントSaaSを運用するかが大事となります。
ここではいくつかの実践的なアイデアが述べられていました。
・コンテナのテレメトリーデータを分析してFargateのサイズ適正化を行う
・イベントドリブンアーキテクチャを利用し、必要な時のみ必要な分だけリソースを利用する
・キャパシティプロバイダーを使ってコスト最適化を行う
セッションは以上でした。
終わりに
「Simplifying multi-tenancy with SaaS applications on AWS Fargate」のセッションレポートをお届けしました。
セッションを受けていて改めて感じたのは、AWS自体が巨大なマルチテナントSaaSの運用者であるということでした。
AWS自身のノウハウが本セッションに詰まっているのだとしたら、使わない手はないな、と思います。
本レポートがどなたかのお役に立てば幸いです。